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This thesis examines the problems of debugging and preservation of the 
user programming environment .and proposes a scheme. by which the program 
development environment can be protected, 
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personal data bases. A protection scheme is proposed that satisfies the needs 
of the user by employing a protection mechanism, rings, that allows the 
program development environment to be protected from user written programs and 
yet be outside of the supervisor. Having these programs outside the 
supervisor satisfies the goals of creating a "security kernel", which is a 
. supervisor containing only security related programs. | 


The thesis presents a model of. the user environment wherein the concept 
of a "procedural package" is explained. The procedural package contains not 
only the code for the procedure, but in addition, . environment components 
necessary for the proper execution of the procedure such as dynamic, static, 
and allocate/free storage. The thesis describes the "inter-procedure 
interference" problem in terms of the model and proposes an ideal solution 
based on a domain architecture. Problems with the ideal solution are 
presented and an alternate solution suggested. 


In addition, the thesis identifies and discusses, in detail, environments 
that are needed to control a user’s. process, and examines error signalling 
mechanisms, particularly in their use in an environment like the one proposed 
to solve the inter-procedure interference problem. 
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Chapter One 


Introduction 


The need for increased efficiency in the use of large systems led 
to the development of multiprogrammed systems, This led the way to the 
development of interactive timesharing systems. Of major concern in the 
design of these systems was the separation of users so that one user 
could not affect the programs, data, or operation of others and yet 
users could still be allowed sence isa sharing. This concern evolved a 
frame of mind which based system design decisions on whether or not a 
user, by any action, could affect the system or another user. 
Self-annihilation (of programs) was. considered legal and permissible 


under these rules as long as this could not affect the system security. 


It is this "laissez faire" attitude towards user programs that is 
dealt with in this thesis. Systems should provide some self-protection 
mechanisms to help users detect and limit the scope. of errors, thus 
speeding up the development of programs. This thesis describes how to 
accomplish this goal by employing a protection mechanism (rings) to 
protect a "program -ehacuieton environment", containing program support 


functions, from user-written programs. 


1.1 Motivation 


As hardware costs come down, the cost of software begins to 
dominate the cost of a computer based product. Helping the programmer 
would therefore reduce software expense and project cost. Numerous 
methods of helping a programmer write a correct program the first time 
have come about and/or are being studied including high-level languages, 
structured programming, module specification, and a programmer ’s 
apprentice (see "Related Work" section). In the long run, current 
research might pay off; but until that happens many programmers will 


face the problem of debugging their software in the "old fashioned" way. 


The proposed program execution environment will help programmers 
catch errors during testing and limit the scope of those errors. This 
capability will undoubtedly speed up program development and thus reduce 


software cost. 


Unfortunately, programs are never completely bug free even after 
years of development. Constant upgrading and changing patterns of use 
may exercise portions of a program that were not considered important 


and therefore not thoroughly tested at the time of the first writing. 


To help in these situations a _ protected program execution 
environment can be employed that would be safe from user program 


modification and could notify the user immediately upon detection of an 
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error instead of letting the.error propagate and cause more extensive 


damage. This monitoring will be referred to as “guarded execution". 


Program development and guarded beeeuy toa justify the work done in 
this thesis, in general. However, the actual motivating force that led 
to this research was the Multics kernel design project being carried on 
in the Computer Systems Research division of Project MAC at M.I.T. 
(presently the M.I.T. Laboratory for Computer’ Science) [Schroeder 75]. 
Appendix A contains a brief discussion of ‘that work and should be 
reviewed if the reader is unfamiliar with the concepts. In summary, 
certification of correctness of the security features of the supervisor 
would be easier if the supervisor were made gastieeic Modules unrelated 
to security vould be removed from the supervisor and placed in the user 
domain. This increase in the number of support modules existing in the 
user domain increases the fragility of the user domain and the possible 
scope of damage that errors can cause there. Thus program development 


becomes a more difficult task. 


The combination of the requirements of certification and _ the 
traditional "don’t care" attitude of the systems developers (described 


in the introduction) resulted in the research reported in this thesis. 


Sila: 


1.2 Plan of the Thesis 


The thesis proper begins in chapter 2 with the description of a 
basic model of a process in a multiprogrammed timesharing system, in 
which Supervisor/User modes are briefly discussed. The User domain is 
then dissected into procedural packages containing basic environment 
components (as opposed to functions) and the problems of access by the 
wrong procedure to those components are discussed. Efficiency 
considerations that led to the Loalesoitiie of distinct components into a 
single object on a particular system are discussed and studied. How 
this coalescing aggravates the problems of incorrect access to 


environment components is explained. 


An ideal solution to the inter-procedure interference problem is 
proposed wherein each procedure would exist in its own protection domain 
and could not affect any of the environment components of another 
procedure. Some basic problems of complexity and efficiency of using 


this approach are discussed. 


A new model of the user domain based on functional units is then 
described in chapter 3. The concept of support routines and command and 
control routines are explained. A new, simpler solution to the 
inter-procedure interference problem is proposed in which the support 
routines are protected as a unit. A mechanism for implementing this new 


proposal is then discussed. 
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Chapter 4 takes a closer look at the support routines and offers 
suggestions for their proper coding so that their protection is 
facilitated. Examples of major modules that need not exist in the 
supervisor and could benefit from protection in the user domain are 


discussed. 


In chapter 5 the programs that a user controls a process with, the 
command and control routines, are studied in detail. Command line 
processing and process. control are discussed. The reason for protecting 
these routines is explained and avasibre methods of protection are 


considered, including a separate process "front end" approach. 


Chapter 6 discusses error signalling mechanisms and their problems. 
These problems can be ignored in a single domain implementation but must 
be considered in order for a multi-domain environment (such as the one 


proposed in this thesis) to work. 


Finally, chapter 7 presents conclusions, a summary of results, and 
comments about a test implementation. Possible areas for future 


research are also discussed. 


Appendix A contains a detailed discussion of certification and 
explains why reducing the size of a system. supervisor facilitates 


verifying its correct operation. 
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1.3 Related Work 


This research was motivated by the kernel design work in the 
Computer Systems Research division of Project ..MAC at MIT (now the 
Laboratory for Computer Science). .. [Schroeder 75] discusses the CSR 
kernel design, project and. the methed of. attack. {Janson 74] and 
{Bratt 75] describe how pregrams responsible fer dynamic linking. and 
Namespace management, respectively, caa be cece from, and thus 
simplify the supervisor. ie ae 76b]) discusses how process 
eréation can be cartialiy peaaved from the supervisor thus aiding in the 


dinpis fication goals. 


Many researchers are investigating techniques to prove programs 
correct and/or bel? users write correct programe: {Parnas 72a] 
describes module specification ‘techniques. “ThAskov 76) is develéging a 
language, CLU, which is chorodghly cyee checked ‘with hopes that it will 
prevent (or reduce) programming errors and Siiow. aucblatic program 
- verification. It allows. the creation of extensible objects which are 
manipulated by type. managers or "CLuetere'’ and: preventa# all other 
programs but the appropriate type mandpenn(tnanialeectly touching the 
"insides" of the extended type object. [Hewitt] describes a 
programmer’s apprentice which should help a program writer avoid such 
errors as incorrect number of parameters to subroutines and wrong types 
of arguments, thus maintaining consistency of specifications, and answer 
the programmer’s questions about dependencies between modules. 
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There are many theses and papers related to the ideal solution 
presented in chapter 2, which is basically a domain peehivecrare: 
[Dennis 64] and {Dennis and Van Horn 65] describe spheres of protection. 
{Schroeder 72] describes’ the favdnete that could support mutually 
suspicious domains. [Redell 74] discusses tyne exteneton and revokable 


capabilities. [Jones 73} describes capabilties in a very formal sense. 


The concepts of command and control environments are discussed in 
this thesis, The General Electric Mark II time-sharing [Montgomery 76a] 
is an example of a system which contains these functions in supervisory 
code which I claim is unnecessary. given the proposed protected 
environment within the user domain. [IBMCP] is an example of a system 
that contains the control environment, but not the command processor, 
within the supervisor. (TENEX] contains the command processing 
functions coded as system calls while the program that accepts user 
commands is in the user domain. [NSW] and [DCS] are examples of current 


research that promote the approach of a front end processor. 


Of course there is much literature on Multics but I have chosen 
{Organick 72] for an overall description of concepts although the 
details have changed somewhat, and [TR123] because of its extensive list 
of references. [Schroeder and Saltzer 72] describe the ring hardware in 


use on Multics today. 


Debugging and maintaining the user’s process is of prime 
consideration in this thesis. Having a debugger protected from user 


written code certainly helps in the job of debugging and guarantees that 
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some portion of the process is preserved despite user programming 
errors. {IBMCP] has a primitive debugger in supervisory code that is 
protected. The debugging system, "NURSE", described by Gould [Gould 75] 
is more extensive than the IBM debugger, but it too is in the 
supervisor. Yates” thesis [Yates 62] contains a proposal for a 
protected debugger that would be an "administrative routine", which is 

also in the supervisor. A better approach is found in [PSN25] and 
{[PSN26] which proposes to protect a debugger in the user domain using 
user controlled base and bound registers on [CTSS]. This approach is 


much like the ring structure proposed in this thesis. 
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Chapter Two 


The Process Model and the User Domain 


In order to describe more accurately the details of this research, 
a model of a user’s computation is needed. The model chosen was based 
on the Multics system; however, chave are nee wane Moretee specific 
items in the model. Those items that are not Seowant in a given system 
can simply be ignored without loss of applicability. The model is 
intended to reflect a typical process in a multiprogramed computer 


environment. 


The term "process" appears throughout this thesis. The association 
one should make with this word, while reading this thesis, is an active 
agent, a processor (real or virtual, i.e. multiplexed), following a 
sequence of instructions. The past, present, and future effects of the 
iusevuseione executed is a process. fhe tevale toeseeaitet and "program" 


are used interchangeably, as are the terms "parameter" and "argument". 
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2.1 Supervisor and User Domains 


First the process is broken down into two scopes of access, or 
"domains", namely "supervisor" and "user", as shown in figure 2.1. The 
figure is intended to indicate that the access privileges of the user 
domain are a subset of the privileges of the supervisor domain. The 
access privileges of the supervisor include access to I/O channels and 
devices, which may be controlled by a different means from data access. 
(1) All interrupts and faults are directed to the supervisor domain so 
that it may properly control the user domain and 1/0. There may be one 
or more real or virtual (multiplexed) processors executing the process, 


but for simplicity only a single processor is assumed. 


Now the user domain is examined, which is where the problem being 


attacked exists. 


(1) For example, Multics uses a privileged state bit in the processor to 
allow execution of I/O instructions. PDP/11’s have no I/O instructions; 
the device registers are addressed as memory locations. 
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Devices | ae | per 
Faults 


Packages 


Fpore 2.1 Supervisor/User Domains 


2.2 Dissecting the User Domain 


The user domain is considered to be the collection of procedures 
that execute there. The code is not the only item that allows a 
procedure to function, though. The description of the user domain will 
consist of what environment is "seen" by programs that run in that 
domain. The user domain is examined in this peculiar way so that the 
program interference problem can more accurately and precisely be 


described. 
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Programs are viewed as "packages" containing the code and 
additional objects that are needed for execution. This section 
identifies those objects that make up the environment necessary for most 
program execution. Much of the environment has been established as 
conventions, but these conventions are indeed necessary for the proper 
execution of programs written in higher level inveuneee: Only passive 
objects are mentioned in this analysis. Functionality that exists 
because of either user or system programs is simply and _ grossly 
categorized as user programs accessible via call, and supervisory 


programs accessible via gates (an abstract entity for supervisor calls). 


The passive objects that this research has identified are small in 
number, but are intended to capture a particular view of the process 
which will be examined shortly. The components are 1) dynamic storage, 
2) allocate/free storage, 3) "own" storage, 4) parameter list, 5) 


parameters, 6) linkage, and 7) databases. 


The dynamic storage area is where blocks of storage are 
automatically allocated each time a procedure in called, and 


automatically freed when the procedure returns. The class of storage is 


known as "automatic" in PL/I. Temporary work areas are typically 
allocated in this area. The allocate/free area is where blocks of 


storage are allocated and freed under direct program control. These 
allocated blocks remain in use even after the procedure that performed 
the allocation has returned. A typical use for this type of area is for 


the allocation of I/0 buffers and I/O access method control blocks (e.g. 
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the index of an ISAM file). "Own" storage, or internal static, is 

automatically allocated upon first entering a procedure and is not 
usually released. The allocation may be implicit, since some systems 
provide this storage class as a physical part of the executing program 
(impure procedures). A typical use for this type of storage is for 
saving information between program invocations, such as whether the 
procedure has initialized a data base, or pointers to blocks of 


Allocate/Free storage. (2) 


The parameter list identifies arguments to the called procedure, 
and may include descriptions of these arguments including type and 
length information. The parameters themselves are typically located in 
some storage external to the called procedure. A linkage section, or 
transfer vector, is used to bind named objects to physical machine 
addresses. Finally, the last component of the procedural package is the 
collection of data bases that are in use by programs. On some systems 


this component can be considered the open files for the program. 


Note that only the parameters and databases are, or need to be, 
external to the procedural package; the other components either should 
exist only in the procedural package, or be copied in. In no case 
should these other components be referenced by external procedures 
unless explicitly passed as parameters. The violation of this maxim is 


exactly the problem that this thesis examines in the next section. 


(2) The compiler does not know the address of Allocate/Free blocks 
because the programmer may allocate them in any procedure and pass 
pointers around. The compiler, however, assumes that internal static is 
allocated in a certain place, possibly pointed to by a register. 
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2.3 The Problem 


The reason for discussing this particular breakdown of the program 
execution environment is that implementation of the specified components 
tend to cause unnecessary common mechanisms between procedures in the 
user domain. For instance, the dynamic storage area is typically 
implemented as a _ single object shared between programs - the "stack". 
Usually the Allocate/Free area is a single area for all of the programs 
in the user domain to share. Linkage is usually implemented as a single 
common transfer vector for an entire collection of programs. On systems 
where programs are kept pure, internal static is not part of the program 
object module and is allocated in an area with all the other static 
sections in the user domain. Parameter lists are typically allocated in 
the dynamic storage area, causing further entaglement of objects. On 
systems which have virtual memory (segmentation), every known segment is 
a potential data base. (3) These examples of the concentration of 
multiple objects into one object which is global, allows one procedure 
to access another’s "piece" of the object. This is possible because 
access control usually extends only to individual objects and not to 
sub-objects. Because of this, one faulty procedure can modify and 


destroy another’s dynamic, allocated, or static storage. 


(3) A known segment is a file of which the address can be constructed. 
On Multics, the address is a two-dimensional quantity (S,0). "Ss" 
represents an index into an array of "open" files, and "0" is the offset 
into the segment S. Hence an arbitrary value for S can select any of 
the open, or known, segments. 

~22— 


This data concentration may result in unpredictable results of 
tested and debugged programs. A ieohaws aay be totally destroyed 
because of one modified bit. Programs may reference the wrong block in 
an allocated/freed, static, or linkage area. File access information 
can be destroyed, causing jumbling and loss of records. Data bases may 
be written instead of read. The stack.may be overwritten or deleted. 
Programs and linkage may be written Sven For those systems (like 
Multics) where gates are actual programs found by the normal linking 
mechanism (as opposed to SVC type fecrioriodeys destroying linkage can 


prevent any further calls to the supervisor. 


An example of the merging of unrelated small objects into one large 
one with no specific access control to Beesene erroneous access is found 
in the current implementation of the Multics stack. In the original 
Multics design, segments were Cabeaned to contain only data requiring 
identical access. This was not followed on Multics when the current 
stack design is examined. Efficiency, related to reduced page faults, 
caused the merging of unrelated data into one object. One segment was 
used for all stack frames, and at the low end of the stack the infamous 


"base of the stack'' was designed. 


This base of the stack contains many special environment 
definitions including. pointers to important entries in PL/I operators 
(i.e. call, save, return, and stack manipulations), to the procedure to 


do the signalling. in that ring, and to the Linkage and Internal Static 
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Offset Tables, (4) to name a few. Again, these objects were all merged 


simply for increased memory utilization. 


Because of the merging of all the above areas into one segment 
which was writeable, one bad stack reference could destroy the entire 


execution environment. 


Until recently, linkage and internal static sections were always 
combined into one static section. This allowed out of range references 


to internal static to affect linkage of programs. 


In order to prevent these types of errors from occurring, and 
possibly to catch them as they occur (for debugging), it would be 
reasonable to protect these elements of the execution environment which 
are common mechanisms. There ase ce existance machines which prevent 
this sort of wild access from occurring, but are limited to stack 
references and a few data types (Organick 73]. Current research has 
shown ways for preventing this type of behavior in general, (5) but they 
are just not applied because of efficiency considerations. In the next 


section an ideal solution and the problems with it will be discussed. 


(4) The Linkage and Internal Static Offset Tables are used by procedures 
to locate their linkage and internal static areas within the segments 
containing all linkage and internal static areas. 


(5) Interpreters and extended type objects and type managers for 
example. 


Soha 


2.4 An Ideal Solution 


To prevent the type of interprocedure interference that could arise 
due to sharing of environment components, a protection mechanism of — 
kind is needed. This protection is required not only for the components 
of the execution environment discussed in the previous section, but for 
the actual code of the veeduves as well. Ideally, the procedural 
package concept would be enforced by the system; each procedure would 
be housed in its own protection domain and be allowed to access only 
objects that it required for operation. These objects might be 
catalogued in a list which would quickly identify all those objects that 
the program in that environment could ever reference. (6). Among: those 
objects would be the components of the execution environment. Only 
required access to each component would be granted so that, for example, 
only read access is allowed for linkage sections and only execute access 
for object segments. Furthermore, the components would not be 
accessible at all outside the program domain unless explicit permission 


were given. This structure is depicted in figure 2.2. 


There should be ways of adding and removing objects from _ the 
"list". These addition and removal operations are necessary so that 


blocks that are allocated and then freed would not be accessible to the 


(6) This could lead to an easily implementable system given appropriate 
hardware. 
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original allocator once they are freed, and so that parameters could be 
passed for use, then removed from the "“list" when the procedure 
returned. These parameter capabilities are shown as dotted capabilities 


in figure 2.2. 


Capa hibity 
Code thoes 


[ Copebrlieres: 


Parameter +! 


Parameter $20 


Figure 2.2 Protected Procedure Package 
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There is some eupense incurred when dealing with a system with this 
architecture, however. Maintenance of the individual capability lists 
for each domain requires an extra database for each program. With a 
sufficiently ices. collection of Bere (as i a typical large 
system), this could involve many sunk objects. In addition, each 
environment component would be a distinct object. Thus, the 
implementation is faced with the management and storage of all these 
objects that exist as ihadectneeee entities. (7) During execution, 
domain changing with every procedure call would undoubtedly be expensive 
because dynamic capabilities would have to be stacked and maintained 
[Schroeder 72]. Excessive paging averhead due.to a new capability list 
and environment components would also decrease efficiency. As pointed 
out earlier in the Multics example, excessive paging overhead is in fact 
what led to some of the problems being attacked in this thesis, 
Returning to the original state of - affairs just for the promise of 
better debuggability is probably not “Burkteteue motivation to reduce 


performance. 


Besides performance issues there may still be a problem in using a 
program per domain system. Examining in detail how a user could create © 
and develop programs points out some problems that have to be overcome 
if such a system is to be considered useable. In particular, consider 
the set of privileges that have to be granted when a new program.is 


created. First, the source must be entered and. edited, which requires 


(7) This problem has come to be known as the "small objects" problem. 
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that an "editor domain" have read and write access to the source. Then 
a compiler must be able to read the source and write the object segment. 
A debugger must be able to read and write the object segment (perhaps 


only temporarily) so that code can be examined and breakpoints set. 


All seems fine so far, but it is in the execution of the procedure 
where the more complex access problems and controls come into view. The 
new procedure must be given the privilege to call all the subroutines it 
uses. Similarly, if it is called by another procedure, that other 
procedure must be given the right to call it. All the support programs 
(e.g. linker, dynamic area manager, etc.) must be given the appropriate 
access so that they may operate on the parts of the domain that they are 
intended to (linkage section, dynamic storage, etc.). Clearly, if users 
had to establish all of these privileges manually, they simply would not 


do it; and what good is a protection mechanism if it is not used? 


To help in this problem one might decide that a group of programs 
should be encapsulated together to alleviate some of the complexity of 
establishing the new protection environment. One can, for example, 
group "system routines" into classes of domains ‘ten require similar 
access, thereby requiring only one access control term or capability for 
each group. With appropriate constraints, it might even be possible to 
reduce the overhead of procedural packages by having relatively few of 
these groups. This approach is exactly what is considered in the next 
chapter where problems and other useful properties of such a design is 


discussed. 
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Chapter Three - 


A New Model 


Because of the deeieieady problems related to maintaining 
independent protection domains for every procedure, the use of a 
simpler, more efficient means of separation was investigated. ee this 
new approach, the user domain is viewed in a different light. Instead 
of trying to separate and protect a user environment program from 
every other, a separation by classes is eousrderea: This new separation 
divides the environment by eacopiote eather than by components and a new 
solution to the problems posed in the previous chapter, based on this 


new division, is proposed. 


3.1 Functional Components in the New Model 


The basic idea of this new approach is to reexamine the user 
process and functionally divide the programs in it. In figure 3.1 the 
gross functionality boundaries are depicted. In this picture it is easy 
to illustrate the goals of the supervisor simplification work discussed 
in appendix A, that strongly motivated this research. This goal is 
simply to move the user/supervisor boundary down to the resource sharing 
and multiplexing functions. By examining the picture, the effect that 
moving this boundary has on the size ine complied ey of the user domain 


is clearly demonstrated. Moving the boundary places more functionality 


-29- 


Domain Poundaries 


Pre- Cert fica kon Vernel Design Goals 


U ser Written 
User 
and User 
Control 5 UpPport 
Superv \sor 
Resource Shaving/ Molai plexing. " Kevnel® 


Figure 3.1 Functional Boundaries 


in the user domain, thus increasing the harm that an unchecked program 
error can cause. For the rest of this work it is assumed that the 
user/supervisor boundary is in fact moved to the point established as a 


goal for the supervisor simplification effort. 


The user domain is considered to be broken down into three classes 
of programs: command and control, support routines, and user programs. 
The command and control programs are those programs that allow users to 
control the execution of their processes (e.g. stop and start) and to 
tell their processes what to do (i.e. what programs to run). These 


programs are unlike any other programs. in the user domain and are 
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therefore considered independently in a later chapter. Until then, the 
command aad control programs shall be ieaceede Procedures that fall 
into the sippote routine class ive those that serve no other pidseua but 
to provide a more elegant enacuact machine for the user programmer. 
These procedures include stack management, Pera save - return macros, 
Input/Output access methods, ‘software for floating point support, 
conversion routines, free storage canacemant: dynamic linking, and 
namespace management, to name a few. These reeset are iguadiy 
provided - the system itself. The user programs are those programs 
written by the user to perform a desired raek: and make extensive use of 


the support routines. 


Partitioning the user. domain in this way allows the. support 
routines to be protected, as a group, from the user programs. It is- 
assumed that the support routines are tested and debugged, and seldom 
change. Thus, a manual: review of the support routines can verify that 
they will ‘ee interfere with each other. Therefore, protecting. the 


support routines as a group should pose no additional problems. 


The support routines are common routines, shared by the user 
programs. A failing support routine would have a more widespread effect 
than a single failing user program. Thus, protecting the support 


routines is in fact protecting some of the common mechanisms of the user 


domain. 
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Protection of the ackuat code is not eke: ony fake. that is wanted 
though. Protecting chose components of the user execution Sees 
discussed earlier so that the support eauetnee Here function 
independently teou the user programs is degteea. The ‘support erence 
cannot be sl toved to share those components.» with user programs. 
nawver, because ne ne correctness of the euppere routines can be eeeenres 
the gigpore routines can be allowed to share tlie environment compeneure 
among themselves. In this way, breakage and ‘therefore “inefficiency in 
memory utilization is held to a miniaus above Enee of the original 
combination of ‘iaee and support routines: This compares | favorably with 
the ideal solution proposed in the previous chapter, where no Buch 
sharing was possible. The “working set". [Denning 68], or number of 
pages of memory required by a computation in: this seheme would be a 
maximum of twice the number required by the original, single environment 
implementation. This is so because there.iare only two: domains where the 
pages. can be and in eaeh domain those pages Caa-be: as: packed as: they 


were in the original. implementation. — 


In ‘summary, two environments have- been: created within: the user 
domain. The next step is to choose a protection ‘mechanism for keeping 
the environments separate. - By examining. thé. dependencies ‘and 
interactions between. tlhe coud -oavttcmseaitashMeudveblevacdhanteateda be 


decided upon. 
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3.2 Deciding on a Protection Mechanism 


The types of functions saveveued Gy the cupuset routines are simple 
and likely to be invoked often. With functions such as the call-return 
sequence and stack management implemented as sida sony iaeus it would 
clearly be impossible to have them exist in an independent address space 
where some outside active agent performs ee Coamiitesttas between the 
two, since these functions are necessary eoney eden the communication. 
Thus, a “distributed processing" approach involving pavaties processes 


is unfeasible. 


Some form of linked address space between the two environments is 
needed so memory can be shared. The support routines must ‘be able to 
manipulate elements of the user programs (stack, linkage, sce) on the 
other hand, it is desired to prevent programs from interfering with any 
of the elements of the support uapeeoanene: This type of nesting of 
privileges very closely parallels the user/supervisor modes discussed 


earlier. 


At fipees planing the support routines in the supervisor might be 
considered. However, appendix A presents reasons why programs which are 
not necessary for correct operation of the system should not be in the 
supervisor. Recent research in system certification {Schroeder 75] has 
crystallized these reasons. Appendix A contains a brief description of 


this work. 
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However, besides certification there are very simple reasons for 
not placing programs in the supervisor. These reasons have to do with 
extendability and maintainability. Sophisticated users of Multics 
greatly appreciate the ease with which they can change and replace 
almost all parts of their execution environment. If the code were in 
the supervisor a user. dissastisfied with the particular implementation 
would be unable to change it. Furthermore, bugs in the code would 
require supervisor changes to correct, which is more often a harder job 
than replacing user programs. A simpler supervisor is obviously more 
easily maintained and upgraded, and can be more quickly learned by new 


system support personnel. 


This point has been reached by noting that the nested privileges 
offered by the familiar user/supervisor modes would be useful for 
protecting the support routines. But reasons for not actually making 
use of this scheme have been pointed out. However, the concept of 
“rings of protection" [Graham 68, Schroeder and Saltzer 72] can be’ used 


here with much success. 


Rings of protection, or more simply just rings, are a 
generalization of the supervisor/user domains discussed earlier. Rings 
are an ordered set of protection environments such that ring j has at 
least as much access’ to data and programs in rings j + 1 through the 
maximum ring number as each of the higher rings themselves do, but only 
controlled access (call, read, or no access) to data and programs in 


rings 0 through j - l. 
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The domains of interest here are totally ordered in terms of access 
privileges. Therefore, rings can be used for their . separation. Thus, 
for example, the supervisor can be put in ring 0, the user environment 
in ring 2, and have the critical programs of the user execution 
environment in ring 1. This seopused structure is shown in figure 3.2 
below. The user support routines are protected from eee programs in 
the same way that the supervisor, is, and yet are not part of the 
supervisor. 
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. Figure 3.2 Proposed Structure 


The significance of this last statement must be emphasized since it 
is a major design goal of this. research. In a correctly designed 
system, the supervisor contains only those programs that enforce the 


security of the system. Outside the supervisor, no code can do anything 
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to interfere with the Senéte taut or dee ehee user. 50 even though the 
support routines are jeoeaeted from the user weitten.code. chevy are 
outside the supervisor and thus: cannot pitect apaten aéeurity, This is 
a wage aid in jeeuriog the Kor teceneut Gt the ititer ager Beotede lon 


mechanisms or system security. 


From the user standpoint, having the supgort. esaciaue outside. the . 
supervisor is beneficial in that users can be granted the privilege to - 
modify or replace the support routines so that their environments can be 
tailored to their needs. — “However, we. need not be éoucacned about 
malicious users since as already explained, they dennot affact the 


supervisor of any user;. they can only degrade their own environment. 


Now that the model and the frotitetsod asthe toe have been chosen, 
it is time to consider: how the finalized design solves the original 
problems stated in chapters one and two. Recall that the major goal was 
to trap errors as.soon as they occurred so that the process would not be 


destroyed and so that debugging could immediately take place: 


With the proposed design, any attempt to wildy store data on the 
support routines ‘thewidbves or in’ thet ‘envitomehtaiS components, would 
cause the hardware to "trap" the offending instruction,. preventing it 
from cont inaing, .,...An error -cendition. would: then. be signalled (see 
chapter six for more information on signaklting) , notifying :the user that 
the error had occured. The exact iat egensoln laud Lagaeiea., causing the 
problem could be determined and subsequently. fixed either by patching. 


and continuing, or rewriting and recompiling the program. 
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Although it may not always be possible to continue, at least the 
process as a whole would be saved. Saving the process allows the user 
to continue working on the development of the program and prevents any 


damage to databases that might have occured if the error was not caught. 


The ideal solution would work just as well but would extend the 
protection to each and every program. However, as stated earlier, the 
support routines change infrequently and could therefore be checked to 
insure that they operate properly together. Thus, the only protection 
needed, at a gross level, is for the support routines, allowing the 


robust environment for program development to be realized. 
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Chapter Four 


A Closer Look at the Support Routines 


This chapter presents more detail on identifying and protecting 
support routines. It describes two methods of protection: One for 
procedures that have no static storage, and another for the more complex 


functions of the user environment with static storage. 


4.1 Two Cases of Support Routines 


Some of the low level support routines on a system require no 
Static storage, linkage, or databases for their operation. Simple 
mathematical algorithms are examples of such routines, where, for 
instance, only processor registers are used. The only protection 
necessary for chains type of routines is for the code itself. Systems 
that feature direct sharing usually provide low level support routines 
in a shared area that is not ei ania by any process. This obviously 
prevents one user from interfering with another. This same sroteceion 
also prevents users from writing over the code and harming themselves. 
Therefore, rings are not needed for these routines; but on systems where 
every user gets a personal, writeable copy of the routines, rings can be 


used. 
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The more complex and interesting protection is for those routines 
with static storage (either internal static, linkage, or external data 
bases). (8) In. these cases, those atic Steunsite must be placed in a 
lower ring for protection. In order for the routines to access’ the 
areas and function properly, they too must be in the same ring as the 
static areas (or lower but would have no additional advantage from being 
there). Code in the lower ring does not prevent the sharing of that 
code between users, since the code is (or can be) pure; The impure 
sections (linkage and internal static) are allocated per process, 


however. 


4.2 Guidelines for Support Routine Coding 


Dependencies among routines must be established to insure that no 
procedure in the lower ring depends on (uses) a procedure in the higher 
ring for its correct operation. If this occurs, then the module in the 


‘higher ring must also be brought into the lower ring. 


Once a module is brought into the lawer ring, suitable entry points 
are made into gates, allowing the outer ring programs to call the inner 


ring procedures only at.the specified entry points. Internal interfaces 


are thus protected. _ 


(8) If allocate/free areas are used some static storage is required to 
remember the location of the allocated block. Otherwise, if the blocks 
are used only during the execution of the procedure and then discarded, 
it is essentially being treated as automatic storage. 
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Parameters that are passed on user calls to gates are validated by 
the ring mechanism to insure that access to the parameters is allowed in 
the calling ring. This prevents the calling ring from specifying areas 
that are inaccessible in the outer ring, but accessible in the inner 
ring. Without such checks, the outer ring could declare that an area 
used for static storage in the inner ring was the area for an output 
argument, thus causing the inner ring to destroy itself. This problem 
is exactly the same as that faced by a user/supervisor interface 
{Schroeder and Saltzer 72] except that here the protection is mainly for 


self protection and debuggability, not system integrity. 


Modularity of the procedures [Parnas 72a, Liskov 72] is necessary 
to help in identifying and separating the user domain into functions so 
that appropriate ones may be protected. Modules that interact strictly 
by standard parameter passing via calls to procedure entrypoints are 
likely to be the best candidates for separation and protection. 
However, modules that interact via.a shared database pose a problem. 
Although parameters are usually passed internally as a shared database, 
there are specific rules for dealing with those parameters. Module 
specifications can specify the range of, and the legal manipulations to 
be performed on _ the parameters. However, there are no specification 
techniques yet devised to specify a limited set of operations when 
dealing with shared databases directly. Thus, the boundaries of modules 
that share a database are not well defined and the dependency between 
modules is hard to establish. [Janson 76] discusses this in some detail 


and has termed modules that share a database as weakly modular. 


-41- 


The way that weak modularity prevents protection of a module is 
seleneioeeae, If one module is placed in an inner ring, it still 
Sesande on the shared area to operate correctly. the shared area must 
remain in the outer ring so that the other module can manipulate it. 
But if the area is in the outer ring, any program there can write on it 


and therefore affect the correct operation of the inner ring module. 


Support routines that can be protected are therefore limited to 
those that do not interact in ways other than through the standard 
call/return mechanism. A poorly designed system (i.e. one in which 
shared databases are the usual means of communicating parameters) can 
thus limit the number of modules protected. Interestingly enough, the 
goals of "clean modular programming" exactly identify those modules that 
can be protected. Functional abstractions and data hiding both provide 


for the type of modules that are acceptable {Parnas 72a, Liskov 72). 


4.3 Examples 


This section presents exatiples of support routines that may be in 
the supervisor but could be moved to the user environment. Although the 
routines could be in the supervisor, they ate not there due to a desire 
for a well designed, certifiable system. Examples chosen are event 
Management, timer managenment, Input Output managément , and namespace 
management . This section also describes how ringé can be used for the 


direct protection of Linkage. 
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In this section, it must be rembered that should one of the support 
routines fail, the process would no donger be abisveoncoatiacs program 
development and debugging. The reason why Keenine. the gurrede: process 
is considered is due to both. the pee and eueade that went into 
creating the process, which may Koneeia s ectieldeeabie amount of 
volatile state information useful for continued work... Therefore 

‘throwing away the "broken" process and acquiring a ‘new, good one is less 
desirable than continuing with the old process. : The failure modes 
considered in this. section are those due to "wild" storage of data in 


sensitive databases needed for continued execution of the process. 


Interprocess communication can be accomplished by direct writing 
into shared memory. However, to avoid busy waiting (9) sedeweeas can go 
to sleep or "blocked" and wait to be "awakened" by another process. 
Only the minimal anount of software éeceacacy for ae goCual process 
blocking and awakening need be in tha supervisor: Multiplexing the 


blocking for various events can be handled by the user. 


In use, a process goes blocked and is resumed when any event is 
sent to it. The user block goutine then vequatie from the sunekviaor a 
list of all the event messages that eve bent: If ches one that ‘the 
process was waiting for is in the wets the user block routine returns to 
the waiting program. Otherwise, is received esedagéec west be saved for 


future reference, and the process goes blocked again. 


(9) Looping while waiting for an event to occur. 
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The integrity of the area containing the list of events known by 
the process and those messages that have arrived but not yet processed 
is vital to the normal execution of the process. Thus this area and its 


manager are ideal candidates for protection. 


Another multiplexed mechanism can eo real and virtual timers. 
Suppose that the supervisor provides for only two timers per process, 
one for absolute time and the other for elapsed virtual (chargeable) cpu 
time. These timers can then be waditivtened .in the user domain thus 
reducing supervisor © complexity.« One way ef accomplishing: this 
multiplexing is to maintain a list of timers in use, sorted by "alarm" 
time, with the time closest to the pecans in the actual timer supported 
by the system. When that timer goes eft, - when a siseak time to the 
present is added to the list, the real timer will he set to the real 
closest time to the present. This list of timers for the timer MANSES? 
is considered another inportaat, but fagii<, support facility of the 


user environment. 


If the hardware of a system is correctly designed, and users do not 
share I/0 devices, only a minimal mechanism need be in the supervisor to 
support user requested input ead output. deste can be allowed to write 
a channel program to control "their" devices and no- athens. The 
supervisor need only start the chanwel Yee the aoropitece device and 


possibly assign storage for the duration of the operation. (10) Only a 


(10) Multics allows users to request that the supervisor not page out a 
page of memory for a short duration 30 1/0 to fixed addresses:can be 
accomplished. 


—44- 


simple interface to the supervisor is needed to identify a set of 1/0 
instructions for a particular channel ~ execute. Device control 
modules should be in the user environment along with all device access 
programs. Higher level database access programs and code reflecting a 
device independent environment should also reside in the user domain. 
Of course I recommend that all these functions reside in the protected 


portion of the user domain. 


Multiplexed devices can be harder to handle. If two users are 
allowed to share portions of a sagte devise (e.g. sections of a single 
disk pack), it would ee impossible to keep this code in the user Asx 
By definition it must reside in the _ supervisor eee it deals with 
resource sharing and multiplexing among indenendoue asera However, in 
the case of one controller with multiple devia (drives), correct 
design of the oAceniiEee sen allow it to be shaved by many sBeeus All 
that is required is to prevent an 1/0 éhanded oreuras from paeening 
devices during its execution. Then only ai ige Hie aupeeuiaer: at the 
time the channel program is’ started, to specify the device on the 
controller. This approach has in fact been. used by Honeywell on their 


single controller, multiple drive tape units for Multics {Greenberg 76]. 


Short reference names are local user defined aaaee that can be 
associated with long global names to simplify talking’ about an object. 
Once the relationship between a reference name and: global: name is made, 
only the short name need be. used. ree example, a reference: name might 


be '"square_root" for a procedure that computes square roots, while the 


-45~ 


global name might indicate the location of that procedure within a 
naming hierarchy such as: 


"ROOT>system_library>math_routines>square root". (11) 


Typically a linker, or binder, associates the reference name as 
used in programs (e.g. x = square_reet fy)) with a particular module in 
the system. As Bratt [Bratt 75] explains in his thesis, the ‘reference 
name facility need not be fin the supervisor. Bratt describes how that 
facility can be removed from the pincediber ani be staced? < the user 
domain. However, this, facility is greatly depended on Ry all programs 
in the user domain. If the reference neme “meadaet should fail, 
inter-program linkage would fail and no new prcereee could be found or 
executed. Thus it is iacatative that this facility be Spobectad’ from 
damage by user programs. Placing end Vataceaee name manager in the 
protected environment is essential es the goal of providing an 


"unbreakable" user environment. 


All the above modules contain significant state information in 
Static storage. Therefore, it would be destrable to place those 
programs in the protected envirenmeat so their important state 


information is protected. 


Finally, consider dynamic linking. Jansea {Janson 74] explains in 
detail how dynamic. linking can be. removed frem the supervisor of an 


operating system. However, here too, the. eventwal placement of the 


(11) A>B indicates B is in directory A. ROOT is the root directory of 
the naming heirarchy. 


-46- 


linker module is in the user domain. The set of search rules, guiding 
the linker to find a specific copy of a named procedure, constitutes a 
Static database used by the linker. To protect the search rules, and 
thus the Linking mechanism, the linker should be placed in the protected 


environment. 


Another part of the linking mechanism that Janson termed 
environment initialization is also important to protect. In Janson’s 
design, a procedure locates its static storage and linkage section when 
it is entered. The first time that the procedure attempts to do this 
will trigger a mechanism which will allocate. and initialize these 
sections. This allocation and initialization processes can be 


protected. 


The tables that procedures use to find their linkage and internal 
Static sections, the Linkage Offset Table and Internal Static Offset 
Table (LOT and ISOT), can also be protected. The LOT and ISOT only have 
to be read by procedures; it is an error if a user program writes in 
them. Similarly, linkage sections are only read by programs. Thus the 
LOT, ISOT and linkage sections can, and should be protected from errors 
caused by user Sgentane. To do this requires placing not only the 
environment initializor in the protected environment, but the linker as 
well, since the linker modifies linkage sections. This approach 
realizes at least part of the original goal of protecting the components 


of the user environment. 


es 
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Chapter Five 


Command and Control Routines 


A human user of a system is aware of other environments besides the 
execution environment. Any program that. accepts input from the user’s 
console interprets what the user types in a different way; hence the 
appearance of different environments. This chapter examines those 
environments that are used to control a process. This research has 
identified two environments used for this purpose, which have slightly 
_ different properties. These environments are embedded in the code that 
was classified as command and Gonteol programa in ‘an earlier section. 


These two environments and their properties are discussed below. 


5.1 Structure of Environments 


The relationship between the user at a terminal, the program 
execution environment and the cat d and contest sav leosnenta is shown 
in figure 5.1 below. Between the terminal and the program execution 
environment flows user program input and program output. Between the 
terminal and the command and control environment flows program loading, 
stop, and start requests, as well as messages frow.the command and 
control environment (e.g. "program not found"). Finally, between the 
program execution environment and the command and control environment 


flows a program generated command stream and control messages such as 
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start, stop, and load a particular program. All these streams will be 


discussed in more detail in later eections. 


Execution 


. Ensen ment 


“Start step or load” 


Figure | Commend ona Cewtsrol Structure. 


Consider the components of ‘figure 5.1... fhe -pregram execution 
environment has :already ‘teen diecsseed in previous chapters and the 
reader is probably femiliar with some terminal on a timesharing system; 
thus, an examination ef the command aad centrol .environment is aeeded to 
complete the picture. Although these enviremrents are show merged into 
one in the figure, :they heve different: properties in reality. Aa 
attempt will be made to deacribe these differences, but as you will see, 
it is hard to separate them entirely. They will then be considered 
merged for the rest of the thesis. 
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5.1.1 Command Environment 


The command environment is seen as the program that the user is in 
communication with immediately after being given a process. In 
particular, the command environment responds to user requests that 
describe what programs to run for the user. After the specified 
programs have completed, the user is again in communication with the 
command environment. Typical requests to the command environment are 
" 


run the editor" or "compile my program" in. whatever syntax is 


understood by the command environment. 


The types of messages that are sent between the command environment 
and the rest of the user domain are basically “load this program and 
transfer to it" in response to a user command, and in the other 
direction "execute this command line as though the user typed it" for 
programs which generate command lines. These messages are shown in the 


figure below as user requests and program requests, respectively. 


User requests are generally familiar to all computer users. It may 
be some form of job control language ("// exec pgm=basic") or one word 
command lines on a timesharing system ("basic"). The use or need of 
program requests might be doubtful though. However, use of this feature 
could be made, for example, for the implementation of a command file 


facility (more will be said about this in a later section). This 
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facility allows users to create a file containing a sequence of commands 
to be executed, and invoked by running ene Raa file program 
specifying that file as it’s input. The ceauiase file procci “thes 
simply calls the command and control environment with each command line 
in sequence. The commend tines jen gacdad to tie command ansivounene 


via the program request stream. 


Another use for this stream is to allow. programs to pass a 
"canned", or user supplied comand. Line to the cémmend environment under 
special circumstances. This feature might be employed in a: procedure 
that sould accept a generic command string ~-and append: or. substitute 
generated information into the strings: ‘Then the coommmnnd processor would 
be called with each such SeEeeated command string thus relieving the 
user from havide’. to type the same comecaai over ; many times. (i example 
of such a procedure would be one “that simply generates a List of new or 
modified information files; invoking, this ) command would eee a ‘list 
of modified or new file names. If the” user mented each one of shies new 
oe modified files to be orinteds he/she could “supply the generic comand 
- string "print 2" to the list_new files command , which outa then 
generate the commands "print new file a", “print help file 3",  ..... 
(etc.). The "%" in the generic command string would be replaced by 
actual file names in each’ generated command. Then the command processor 


would be called with each of the formatted command lIiines. :(12) 


(12) This is just an example and not a proposal. 


By 


5.1.2 Control Environment 


Whereas’ the cjqumand environment quietly waits for requested 
programs to complete, the control environment is always awake and 
listening to the user (at least conceneuniiyy. The exact mechanism that 
is used is not important here; what is important is that at any time the 
user can say "hey you (computer or process), stop and talk to me !". In 
this way, the user can stop an infinite loop in a program and not waste 
time and/or resources waiting for a failing program to complete. Along 
with the power to say "stop", the user would also like to say "OK, go 


ahead", or "forget that". 


Functionally, the user generates a signal causing the process to 
enter the control environment. (13) Users then have a choice of 
debugging and continuing, or forgetting the computation. They may also 
run any other program first, before returning to: the stopped program. 
In this way, a calculator program can be used to check intermediate 
results. Similarly, an inter-user message facility can be used ae ask 
the author of a program "hey, what’s wrong ?", get a response, then 
continue the interrupted program. This general: program calling. can be 


implemented by allowing the control environment to call the command 


(13) On Multics, users generate this signal by using the "break" or 
"attention" key on their terminals. On TENEX, control-C generally does 
the same thing. , 3 


-53- 


environment to process all but control environment requests. However, 
control environment requests might actually be parsed by the command 
environment and inveke control environment Bennvione. (14) | ‘This 
apparent double dependency can be resolved by joining the two 
environments, thus providing.» single commend: environsent to the user 


which is simpler in structure and more easily understood. 


In summary, the major difference between: the control. and command 
environments is that the conerod environment is asynchronous with the 
rest of the. user process flow, and. responds: to’: simple, base . level 
requests, with ‘possible extensions:.to: ineludé: full command processing. 
For the rest of this thesis, the two envdroutients are: considered. merged 


into one. 


5.2 Processing Commands: 


This section examines the..detadis. of how a command may be- 
processed. There are, of course, numerous: ways to accomplish the type 
of processing described ‘in this sectton.(see: (Broughton) for example), 
but.. the ones chosen. are useful far.exphadiniag. some protection problems 
that will be described later in this chapter. “The processing ‘described 


covers a large variety. of known systens. 


(14) This is done on Multics where the command environment: processes all 
requests, some of which invoke control environment modules. 


Shu 


In an overall view, the command environment performs four 
operations in response to a user request to execute a module. First it 
parses the command line and performs possible substitutions, parameter 
evaluations, and conditional evaluations. fe een baatehea: for the 
identified (possibly ambiguously named) module using a_ set “of search 
rules. The module is then brought into the addresa space of the user. 


Finally, the module is transferred to and it begins executing. 


Note that none of these functions require that the command 
environment be part of the supervisor; no special privileges are needed 
to perform all of the functions stated. . Even so, some systems [TENEX, 
CTSS] have the command environment as part.of the supervisor. Placing 
the command aiveroeent: in the supervisor suffers from the problems 
discussed in chapter three.. If the venwais for having ave command 
environment pepeected is solely for the benefit of the users, (i.e. they 
cannot destroy the command ins i oimane) ¢ then the: discussion on 
protection, later on in this chapter, should help, in choosing a. new 


approach to solving that problem. 


The functions of the command environment are now examined in 
detail. The tranlating and parameter evaluation mechanisms are examined 
first because they are particularly important in this work. A modular 
design of command processing is described. The modules are classified 
into two categories: 1) those that look at every command line, and 2) 
those that are optional and look at command lines only when asked. This 
classification will be referred to later on in this. chapter when the 


protection of the command and control. environment. is discussed. 
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5.2.1 Text Substitution 


Ceanslation; oe subecttution of text, can be a complicated task if | 
it is not restricted. What is meant here is simply the substitution of 
one string of whee tantea for aanihee in the command line. A frequently | 
used form of this type of processing is for abbreviations. For example, 
a user types "fortim" and gets "fortran <list -map" which might execute 
the Fortran compiler and provide a listing and statement map. This type 
of processing can be neatly packaged in a “front-end filter" preceding 
the actual command proceasor as shown in figure 5.2 below. 

This approach is useful because the abbreviation processor can be coded 
‘in a separate module (allowing easier debugging) and inserted only if 
desired. This module is considered a member of the “always used" 
category since, once it is wavlaceea and inserted in the command 
processing path, it examines every command line to determine if 


substitutions are necessary. 


5.2.2 Parameter Evaluation 


A second aspect of command processing that is considered here deals 
with how commands can be affected or controlled by the user’s total 
environment. With this flexibility users can control the execution of a 


command based on the date, a list of files in a catalogue or directory, — 


Command 
: —Emnvonment 
ee 


Fortean “not - “ 


“Cortlm" 


“Command 
Processor 


“Voad Serkan” 


Figure 5.20 Abbrevation Processing 


or on the name of the person who sent them the last message (for 
example). Use of these controls easily visas petaeise of only new 
messages (those that have been created bolayy compilation of all 
FORTRAN programs in a certain directory, or-replying to the last person 
who sent you an interactive sgesece. without ever “having to specify the 


date, list of files, or the name of the last message sender. 


Such features can be implemented as a special cases in the command 
processor and use special keywords. However, the most general approach 
is simply to call procedures which implement each function and return a 


string to the command processor as a result. Such an approach is used 


aS Je 


on Multics; these special functions are referred to as "active 


functions" [MPM]. The active function processor evaluates all active 
functions in a command line and then calls the command processor with 
the resulting string. Figure 5.3 shewa how the example stated earlier 


works in combination with the abbreviation processor. 
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Figure $.3 Total Command Procecging 
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The program invocation mechanism of the active function processor 
and command — processor are very similar since both call procedures. 
Therefore it is possible to merge these two functions into one. (15) 
However, the modules will be Seiwlaeved independent to facilitate the 
protection discussion later in this chapter. “The” active function 
processor also looks at every command line to see if deCinecBinset one 
must be invoked. Thus, it too belongs to the "always used" category of 
command processing functions. Notice. that the active functions 
themselves are not always used and thus the seitreseron of active 


i 


functions are members of the "optional" category. 


5.2.3 Command Files 


On many systems long sequences of commands may be eeored an a file 
and executed by only typing a single command line. This type of 
processing is useful for reducing typing time ‘and eliminating errors, 
for providing complex "abbreviations", and for  eeeining a simpler 
interface to a complex system (e.g. catalogued procedures) . Most such 
implementations allow parameter dunetd curious and offer a language to 

" 


control execution and flow within the command file (e.g. "if... and 


"go to ..."), including error handling (e.g. "on error go to .."). 


(15) This is done on Multics. 


oem 


Such processing can be merged into the command processor, but for 
the sake of mosu ter tty and clean cesten it should be a Srperete module 
which reads the command file and calls the comes processor with each 
command line. This type of processing also need not be prdeectsd in any 
way (at least for system security reasons) aad therefore can execute in 
the user Aeaate making use of the “program request": “stvcen described 
earlier. If implemented as a separate ‘program, the command file 
interpreter does not look at every command lines it aie only invoked 
when the user specifies ‘ual it should be. Thus, the command file 
interpreter is considered a member of the "optional" command processing 


functions. 


5.2.4 The Command Processor 


After all the command line piambacas is Scapietes- the commana 
processor is called to invoke the specified progran. ‘The progran name 
in the command line fe used to find the actual procedure within _the 
naming heirarchy. The linker search — eee may be used for this 
purpose which, if used, would provide a singia search strategy in the 
user domain for both dynamic Linking and’ command progran locating; one 


search strategy is obviously more easily remembered than two. 


The parameters supplied on. the command line are formatted 
appropriately for passage to the specified procedure. The "load 


program" signal is sent to the program execution environment, which may 


pe eters Ce ee 


cause the program module to be read into main memory, or merely assign 
the module a virtual address (making it "known"; see [Bratt 75) for 
details). Finally, the "go" signal (which may simply be a transfer 


instruction), starts the loaded procedure. 


Obviously, the command processor is the key module in the command 


environment and thus is a necessary and always. used function. 


5.3 Getting to the Control Environment 


The simplistic approach to entering the control environment is 
merely to transfer control from the executing program directly to the 
control environment procedures, much like an. interrupt, sequence. 
However, there are times when users wish to program their subsystems 
with internal "attention" procedures which get.invoked. at the time a 
stop request is issued from the control environment. These procedures 
can be used to cancel the effects of a request that .is currently being 
worked on, or to make a database consistent (e.g. unlock it). For 
example, when LISP on Multics [Reed 76a] recognizes that the user wishes 
to stop the computation, it first. updates all bindings. in memory from 
the working registers so that the most recent effects will be seen by 
the user without explicit knowledge of register -optimization built into 
the LISP subsystem. Only then does LISP allow-the "stop" to take 


effect. 
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However, if the subsystem is malfunctioning, it would be impossible 
for a user to abort it and return to the command environment. 
Therefore, there is a need for at least two kinds of stop Signals; one 
which allows attention procedures to be invoked, and a second which goes 
directly to the control environment. Then users can first attempt the 
more elegant stop, allowing the procedure to recover, but if that fails, 


they can use the "panic stop". 


To implement this type of feature there must be a way of specifying 
the type of stop desired. The "break" or "attention" key found on most 
terminals is usually used as the "stop button" but there is only one of 
them. This can be multiplexed by having users type a single character 
after the break key denoting what type of stop is desired, or Oy some 
coding in the number of breaks sent. The latter approach is prone to 
misuse however, because impatient users would wonder whether a _ single 
break got through if no result of that fact is quickly demonstrated and 
then would send a second break which would get them into the wrong 
environment. The TENEX system [TENEX] has the useful feature of 
allowing all control characters (16) to generate a variety of process 
interrupts. In this way no multiplexing of the break key need be done, 
and simple one character strokes can effect desired responses. Each 
control character can then invoke a special independent function. 
TENEX, for example, responds to control T by first beeping (indicating 
that the system is still there), and then giving a system load estimate 


and resources used since the last request. 


(16) A keyboard character sent with the control (CTRL) key pressed 
simultaneously. 
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5.4 Implementation of Command and Control Environments 


How the command and control environments are implemented is of 
concern because they may be implemented as user nedueatie running 
unprotected in the user execution ate ieomieneseas oo Maneses | Tf this 
is the case, then these programs ate also subject to interference from 
other user programs as discussed earlier = Control se a process is an 
essential feature; therefore in providing a robust environment it is 
necessary to protect the command and control environment. How these 


programs can be protected is now considered. 


5.5 Protecting the Command and Control Environments 


Protecting the command and sonktot environment geane that the 
procedural packages inal ewontiag that ddviponient must be protected. 
The choices for doing this basically fall taco. two Wacesurioa: The 
programs can exist in independent processes” with separate address 
spaces, or they can share an address space and .memory with the user 
programs, as the support routines. were allowed. to do. The types of 
interactions between these programs and the others of the user domain 


can help in deciding which one to choose. 
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The messages to the command environment are simple character 
strings. For the control environment, messages are, more or less, 
"stop" and "go". Because of ie dais of ches aceasta they _ sent 
infrequently (usually once ‘per user request). For this reason 1 tight 
coupling, by memory sharing, between the two environments is not 
Beceseaeys and efficiency of communication 1 not that important. Thus, 
virtual processors, or. physical separation night “BRove to be feasible, 
particularly in light of the current trend towards “distributed 


computing". 


The National Software Works project [NSW] uses the approach of a 
"front end" computer as a user to computer network interface. The front 
end has some memory and a moderate amount of processing power. It can 
parse user requests and format them into a ‘more. eiett eyarer easily 
processed on a vecibes of host benmacare: “Thus, front end processing 
can alleviate some load on the hoee: The front is can also PEON SE a 
more reliable comput ing utility by having low level software choose 
different compueges to eae es poreee requests, ‘in the event of failure. 


The Distributed Goanutinx System [DCS] has this seats in minds 


Meant end processor can also suppert Toca] ‘editing, allowing a4 
user to compose and edit text without making use of the host computer, 
thus further reducing the loadon the host. ‘Character at a time echoing 
can be supported by the front end with spectal “action” keys forcing the 
transmission of words or lines to the host. This approach alleviates 


the need for the host computer to respond to each character typed by 


each user and thus also helps in reducing system load. This last 
facility is in fact currently being implemented on the ARPANET [ARPANET, 


RCTE]. 


There are, hoewyac: problems with this: approach, one of which has 
to do with the program "loading" feature of the command environment. 
The other problem is that some form of communication is needed between 
the control, command and user environments. ._ The loading function and 
communication mechanism can, of course, be in the supervisor, but 
arguments have already been presented for aot placing similar basic 
functions not relating to system security there. The best place for 
these features is in the user environment, but as mentioned many times, 
programs are subject to failure there. To prevent this, the 
communication mechanism at the user environment end, and the program 
loading function, can be slaced in the protected ‘gupnone routine. 


environment described earlier. 


Another reason for not using multiple processes.is that the "stop 
and go" features of the control environment can very simply be 
implemented if there is only one execution point in the user’s 
computation. It is obvious that if some signal from the user causes 
immediate transfer to the control environment, the user program will 
automatically be stopped (much like an interrupt). Similarly, when the 
control environment transfers back to the user. program (much like a 


return from interrupt sequence), the "go" function is obtained. 
q 


ahha 


There are arguments for not having interrupts, however, mainly 
babed on complexity and sania ee cppeeiees that service them. The 
environment that the interrupt handlers run in is generally fragile and 
not soupletely specified due to possftte fincriows affecting it that 
were in progress at the time of the interruptict!: The preferred option 
is to use prosedeie Winks appropriate. These processes simply wait for 
the desired signal, then act decordtigty fit a syncirdrious manner. When 
the job is done, the process then g6es "Blocked" wetting fot the signal 
to octur again. In thts | way, the “nv itvvimedt’* that the tnterript 


handlers run in is well defined. 


This scheme does not eliminate the need for interrupts, however, 
but limits the code that must be run during the actual interrupt 
Dedeawe aces that which ercas scheduling functions. By nature,, 
these achedulinn pouch isew ake deatgaed to execute a a acnter that does 
not require full system capabilties. For cee extant SS icatae of the 
user execution envirotment, real interrupts mubt’ aed be used so that 


control can be torn away from the execeting code. 


I have no argument against the use’ of ‘processes for such’ functions — 
except that on a large system, Like Multiés, Where’ processes are very 
powerful processing agents, the expense is siply too great. It would 
be advantageous to ptovide cheap, #eaker prétesses' to perform these 
functions for simplicity of coding: and anderstendibitity. How processes 
can be implemented cheaply is discussed by Reed in his thesis 


{Reed 76b]. Such processes were used by a memory management design with 
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much success [Huber]. Lacking these cheap processes, it was decided to 
place these functions in the environment already set up for the support 
routines. This gives us the simple uteat over the process discussed 
above (because of the _ single execution sates and requires no 


additional tools for multi-process intercommunication to be developed. 


5.6 Design Decisions Based on the Protection Scheme 


The following sections describe decisions that were made solely 
because of the decision to place the command and control environment in 
the protected half of the user domain. In using a different approach, 
such as multiple processes, it is not immediately clear that the same 
decisions would have been made although given some thought, it would 
seem that they are not totally unreasonable because of other criteria 


such as delay time and load transfer to the front end processor. 


5.6.1 Command Processing Revisited 


As a result of placing the command and control environment. in the 
protected half of the user domain, design decisions have to be made 
regarding the placement of each of the command environment modules. The 
major factor that influenced the decisions discussed below was the 
desire to provide a path to the command processor that was unaffected 


by failures in the unprotected half of the user domain so that control 
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over the process could be maintained. Thus the “always used” modules, 
categorized earlier, are precisely the once that must be in the 
protected environment. The "optional" seas need not be, nouevers 
Unlike the decisions made in the eertificetion work dteeGaed tn 
appendix A, there is no exact minimal saeae scaecaun Chae hive a0 be 
protected. The choice can therefore be based on considerations other 
than security. One rule that can be used is “if'-it canbe protected it 
should be", but this might lead to protecting the entire collection of 

programs in the user domain. While this is not a real problem, it 
clutters up the proteeted environment with many simple programs that are 
not essential support modules, Although it sould be deairable to 

protect all programs, as in the ideal selution presented in chapter two, 
we must remember that the preservatian of the .precess and control over 
it is of paramount importance.and the leas of .a.eimple function could be 
remedied dynamically when it is. disaovered,,.. Keeping the protected 
environment simple also helps in understanding and maintaining it 


leading to a more robust environment, 


Obviously the command processor itself must be placed in the 
protected environment, as it is hacceawmeiel component of the. command 
environment. The active function (precessor..nust:: also exist im the 
protected environment because. if it. fatls, no command line will get 
thedush to the command. processor, However, the. active functions 
themselves should not execute within the protected environment for three 
reasons. First of all, they may be user supplied and might. be in the 


process of being debugged. Secondly, the protected environment is 
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different from the one the user "sees". The working environment is 
‘supposed to be the pie eae controls the execution of he command. But 
by executing in the protected sayiesnacnt, etig. functions refer to the 
wrong working environment. Within the protected environment the active 
functions have acceas to more areas than the normal user programs, and 
know about more files or information than the user intended. 
Consequently, they might specify operations that should not or cannot be 

done (e.g. compile the command processor because its name areca "all 
PL/I programs") . There can also be naming conflicts between the 
protected environment and the normal execution: environment. The user 
May request the compilation of a new version of a program but get the 
old one because it is found in the protected environment. Finally, 
active functions are not required in order to pass a simple command line 
to the command processor, which is all that is desired for process 


control. 


The abbreviation processor must exist in the protected environment 
because it looks at every command line and could prevent any commands — 


from getting through to the command processor if it fails. 


Finally, the command file processor need not be in the protected 
environment since it is not used for simple command lines and can 
therefore execute in the unprotected part of the user domain without 
fear of loss of control over the process. The choice of placement of 
this module was just a matter of taste and could have, just as easily, 


been placed in the protected environment. However, the decision for its 
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placement was also due to a desire to ‘not. clutter up the peorcered 


envionment with non-essential support aodulen. 


5.6.2 Command Processor. Escape. Mechanionm 


Since the placement of the command and ceatrol environment: programs 
are in the protected enviroement, some user commands have to. be. executed 
in the protected environment. In particular, ali. control... environment 
commands such as "start", te contiaue a stopped computation, and 
"release", to abaadon a computation, have to be executed within the 
danteal environment. Since only one command interpreter exists, it has 
to know that it should treat these commands differently. Thus, a table 
of commands to execute in the protected environment..¢an be used which is 


looked at by the command interpreter. 


it is also useful to provide an additional mechanism: for users to 
specify execution of a command in the protected environment for just 
that one instance. An example of such a progeam -might. de the «access 
control eettrns program. cueueras. in the user peveren CAV TTORREREs the 
access control program could not ‘affect, ‘prograns in the: protected 
environment; this could Sig: be “done: from within the protected 
environment (this ‘is exactly what is wanted, ‘normally . Mowevat. a user 
might want to “invoke the access ‘control program once for specifically 


setting the access ‘control list on a protected program, soseibly for 


installing a new version of the poumane processor, and at another time 
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escape mechanism is necessary. Justification for allowing this” and 
still claiming to offer some protection for the support coutined is 
found in the belief that the type of error described is a rare one and 
not sxbecred to occur. After all, it is assumed that the user programs 
are not malicious in nature. Thus nsintatning this feature provides a 


single user interface to ‘the command Processor. 


An important question that might be -pudzling ‘the reader at this 


point is "why should anyone trust user programs to behave respec tably 


2", This question deserves a good anawer and:is an “important part of | 


the overall design. Recali that ali: system security related prograns 


exist in the supervisor and are ae aTee all users; once beyond 
the supervisor Soundary, one user cannot affect another. “Partitioning 
the user domain only helped the user pan self ‘kena no “additional side 
effects could occur. Thus, a ‘truly malicious user, using the Sea kouta 
system, could only affect the user portion of the process. No other 
user process, nor ayetem PEOeran could be damaged. The a ee 


ts 


is merely an optional aid to a willing user and not a must. 
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to merely add someone’s identifier to a user program’s access control 
list. The ere control program should not always execute in the 
protected environment or it will have more access than it needs most of 

the time. This extra "greedon" allows mistakes to have more serious 
effects than they would have had Stherutens (17) Thus, the escape 
mechanism allows users to explicitly specify the times when commands 
should execute with increased ‘ye ediege: All sites times, commands 
execute in the less privileged user execution environment (except for 
those listed in the "special" list). Letting a program execute with 
only enough access and privilege to do its job has been a design goal 


known for many years and is discussed in {Saltzer and Schroeder 75). 


The command processor escape mechanism coupled with the feature of 
allowing user programs to call the command processor seems to point out 
a gaping hole in the protection of the support routines and the command 
and control environment programs. Apparently, any user program could 
call the command processor with the escape mechanism and cause a failing 


user program to execute in the protected environment and destroy it. 


One simple and obvious solution to this problem is to have the 
command processor recognize from which any droiiedt it is being invoked 
and ignore the escape mechanism in calls from user programs. However, 
this presents a different user interface and might possibly confuse 
users who wish to make use of the aeane mechanism from within another 


program, such as the editor. For this reason, I feel that allowing the 


(17) This is similar to the major problem reported in this thesis. 
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Chapter Six 


Signalling 


Signalling is discussed in this separate chapter mainly because it 
is a subject that can be factored out for simplicity. The reason for 
discussing signalling at all is due to the problems that appear when two 
domains interact so that signals can pass between them. This structure 
is relevant because of the method chosen sestect support routines of 


the execution environment. 


To treat this subject properly a model of signalling is described. 
Extensions to this basic model are then introduced so that it is useable 
in real er situations. Problems with signalling are then discussed 
to point out basic pitfalls in the original model of signalling. A 
solution to those problems is suggested that is based on a newly 
designed language (CLU). Finally, apabraae: errr related to 
Signalling in multiple rings are presented and discussed in the context 


of the model, its problems, and the solution presented. 
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6.1 Purpose of Signalling 


Signalling allows the establishment of a procedure cat. knows how 
to deal with a particular situation, cauaily an error condition, and 
invokes that Sicceduee at the time the condition is detected. Return 
codes (an output parameter? whose value indicates success or failure of 
an operation) are often Goud to dénote error "gt tuations: Signalling 
differs from simple return codes achans the ocadure to handle the 
error is called at the time the error te detected and may. allow the 
computation to proceed instead. of simply. undoing the computation and 


returning. 


6.2 A Model for Signalling 


The PL/I language has a facility, described in the next batageaghs 
for. dynamically setting up, calling, ént sumewing condition handlers 
[Noble 69]. The method used for choosing which condition handler to 
invoke is straightforward and generally familiar and thus will be used 
as the basic model for signalling. The signalling mechanism used on 
Multics is based on this structure. I believe that Multics is the only 
system on which the entire collection of scttware operates under a 
common signalling ecomauork: Thus it seems reasonable to use PL/I as a 


model. 


a fe 


In PL/I, handlers for various conditions are established by. the 
execution of the "ON" statement. Multiple handlers may be set up for 
any condition in different procedures. “The most recently established 
handler will. be the one that is invoked upon decsteion of the condition. 
Handlers are automatically reverted when the establishing procedure 


returns. 


This mechanism allows any. procedure to-handle an-error locally or 
pass handling on to a system default handler or handler supplied by the 
calling procedure. Local handling is considered more. appropriate by 
some since the local procedure is more aware of the actual situation at 
hand at the time of the error. Parnas [Parnas 72b} however, describes 
how a high level routine may, in fact, be better equipped to. handle an 
error than a low level procedure simply because it understands the more 
global context and significance of the error. More will be said about 


this later. 
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6.3 Extensions to Signalling 


It has been found that ates ale to note the sgckieeasen of an 
error but not handle it explicitly is useful. Similarly, babine only 
partial action ‘towards fixing » the problem: might be desired. Using 
Parnas” -example, an 1/0 routine may discover a read error ibut does not 
explicitly handle the error since it is not ‘aware:of the use or need of 
the record. It may however:desire to maintain local error statistics 
and then ask its caller whether it ‘should ‘retry or ‘ignore the operation. 
In these types of -eases:: Goodenough’s [Gaodenouwgl::75) “PASS .cperation 
might prove -usefwl.  ?ASS<al lows « handier to. explicitly disclaim 
interest. in (further) “processing of ian. excsptiow,:: directing ‘that the 


exception be passed on to some higher handler". 


Working in harmony with PASS is the useful extension of having a 
handler for any condition that is not explicitly named in a procedure. 
The condition name “any other" [MPM] is used on Multics for this 
purpose. This extension is useful in light of the previous example 
where the tape I/O routine wanted to detect all errors and just: make a 
note of them, then pass them on. It would be extremely awkward to list 
all possible conditions that could arise at any point and have the same 
processing for each. Furthermore, since error conditions can be user 
defined, it may not even be possible to identify all the errors that 


could arise. The any other handler solves these problems. 
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A third extension to the  gignalling mechanism is the "cleanup" 
condition [MPM, Goodenough 75]. This condition is semana in every 
block that is abnormally terminated (i.e. does not execute a "return" 
sequence). A handler _that specifies the Perainarise of a procedure 
because of an error automatically triggers this *acchanion in the 
procedure(s) implementing that operation. This allows the procedure(s) 
to restore the original state of and/or eliminate "impossible states" 


(Parnas 72b] in its operation. 


6.4 Signalling Problems 


With the basics explained, it is now. possible to discuss the 
problems associated with a PL/I-like signalling mechanism. The problems 
all arise from the ability for a handler to be set up in one procedure 
that can handle conditions arising in another procedure. This “feature” 
was introduced to overcome the "inconvenience" of specifying a single 
handler in separately compiled external procedures (multiple times). 
This "dynamic descendence" rule [Noble 69] of PL/I violates modularity 


and thus understandability of programs in two ways. 


First a low level procedure must know how its callers will react to 
errors arising in the procedure so that it will know what to expect from 
incomplete operations within itself (e.g. overflow). Thus, it cannot be 
programmed without knowledge of “layers" that use it and so it is not 


modular. A procedure may not be expecting any particular action from 
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its callers; it could depend on the system default handlers. However, 
any procedure may handle its own errors and unintentionally also handle 
errors of programs that it calls simply because it has a handler for 


itself. 


Secondly, a high level procedure that handies errors of low level 
procedures must know the way, in which the error wae caused in the low 
level so that it can handle it properly ‘(e.g.° overflow results in 


highest positive or negative value). 


A final problem arises when error handlers ' themselves’ generate 
errors. In this situation the wrong handler may be chosen to handle the 
error. Consider two procedures <A> and! <B> both’ having ‘condition 
handlers for various conditions. ‘<A> calis ¢B> ‘resulting in an error in 
<B>. <B> does not have a handler fer that’ étror, @kpecting that the 
system default error handler will suffice, or that its‘caller will know 
what to do.. Assuming <A> does heave a andler fer that error (call the 
handler -<A’>):, the eall stack will look:like the: Figure: 6.1 below.’ Now 
if <A’> should take an error like “overflow, <B>’s handler could get 
invoked even though the module <A‘ was’ prepared for handling <A’>’s 
errors! <B>’s handler could obviously choose & completely different 
method than <A> for handling the errot and thus <A’> will not function 


properly. 


These problems all arise from the tncomptete specification of error 
handling within each module. I am not atguing for not allowing higher 


level handlers to "handle" errors of low level procedures; I agree with 
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Stack 
Growth 


Figure G.) Somple Call Stack 


Parnas that this is reasonable, subject .to ‘certain restrictions. I 

contend (like Parnas) that these mechanigms should be explicitly coded 
into the procedures. The "inconvenience" of doing this would be more 
than paid off in terms of understandability and iGue of debugging of 


such software. 


Thus, every module would explicitly detail its error handling 
intentions with possible options like "ON ANY_OTHER CALL 
SYSTEM DEFAULT HANDLER" or "ON ANY OTHER ABQRT" for the conditions not 
explicitly handled in the procedure itself. For passing of conditions 
upward the "pass" mechanism may be employed but I think that passing on 
the same condition that arose in the low level procedure is a violation 
of modularity since the operation of the low level procedure must be 
known by the high level procedure in order to effectively deal with the 
error. A better approach would be to have the low level call a high 


level routine allowing it to return values such as "abort", "continue", 
g 
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"retry", or "use this answer" tn a more global sense. In this way the 
types of responses are known in ceed: More will be said on this in 
the next section. Either a the “error handling should still be 
explicit and have the programmer aia: oe reader aware of what is 


going on. 


The CLU language [Liskov] stovides for just such explicitness in 
error handling [CLUnote 43, CLUnote 60) . “Any error not handled by a 
procedure automatically causes that Shinai: to be terminated and 
results in a “failure. of eectnaten! | conditive: to , be ‘eignailed to its 
caller. Any upward "traps" (Parnas 728) (higher Level -handfiing of low 


level errors) must be explicitly coded. — 


The only probles’ with clo pi to ) do with debugging. i mepect. is 
extremely dmportant since ie isa ae eeéta of concern in enie thesis. 
On Multics there is a default error handler at the “hase. of the stack" 
that performs the “standard fixup" or #éporté an wilandled error'to the 
user and enters a new level of comand enviroment for debugging. Sitrce 
the default error handler te-called, the stack history fa preserved and 
debugging is possibile. Unfortunately, Sn CHU; an‘‘anhandled | error 
terminates the procedure ‘so no dynamic éebuyging is possible. CLY 
enthusiasts claim that "debugging ‘mode" cart be ‘turned ‘on -thué preventing 
any terminations due. to a faiture of mcctatitem, but this has two 


problems assdciated with it. vate wig 


First, debugging ode must ‘be explicitly enabled; ‘the Multics 


default handler is always. there. of course, at. could alvays be. enabled 


‘but that leads to another probles. this ‘second roblem | is. Chae. a 
aL E o ROLRAL ota Po 


normal, expected failure. of. _nechanian error thae con Be properly handled 


by the calling proeadine is also £ and told te: the user. Thug the. 
an ri 20h hebbeitg. sk peaks rigs me brebarie getmvecs 


computation could not continue without ee: annoying. measages xed : 
o ewetiol anette Jala a Bory $a RP tt. GRGRAOT VE 


having to type “continue” or  sonetbiog 


athe Tbe! Bate Res SB og + Ss 5 Pe: Crd. 


‘Beets Z wy 


“sda 


° The: ony: epLuciiots: ¥ habeicome es whet car Pmt fethia te ta | 
termination of ‘thee! procedure wots cased wel, wit he oats As 


ae Pio Mo” ts 


‘prepared: te hawdie that comition and at, besa 
et lye nie aleds oT Bo 


te: cohtanes peeber att | ab Sot, = aheeie 
ptociedure: 10: prepekied' or his Laentiche ae a eine or weer 
‘eight nOeEPLer heen “be calael a “ein AR AE RTL We avastonte 
sprememst r on sadaid mils yond eee G0 anki band .daveak 


mb fe dR AW aE Qk oe Cae blues Sf BOtseuss imadolg - 
Given that auch | a | mechanian contd be put ; in cl, it would em thee’ 
ube wie Seals ad sbe gs ida Ssorrensk aiai’ “ybstsgteh 


‘the ideal signalling wechanism would se acaiteble. cae a 
paar wit walls gus Rises pats tewol aff .aaer ¥ some aad 1a paises. 


Seere 


teebooopacts va merbige NEO E S368: SEND ipnzegat ai bead. PO BAER 
hahes eT CE Bawls ag at “hey yaa. bartgot + eee bbn gy 


tes Gi § VASES Me RUSS Nae Ee bissade pais -powed ong “ges ete s tent inka | 


abl iyae vesS Suki che seutett gedh 27nd elke. entedgeeolo #1 sd. ones 


oe bake fi a8 fleet Rees i Mee: eT os agit ee eee er ee ee 
Sey) TR a a Bae Te AP OT eER Sa bite” uh gr iac.cse Be nd 
’ inte gir, « gee : B oe 
CP pesto “MAA bo agers fe FL VHS 
: eee 5. gue Te eegege | SES ge ea eS Pr eo 
o cae BMepsW Ae BLE E pSV RTS 3, t FER hes Read Pits 


Cami rity aw beg esas onic pd Bived& Net datno teak ee 


6.5 Multi-Ring Signalling 


Assusing standard PL/I signalling ts provided for ‘dn a multi-ring 
siviroument the first problem that ations follows a stnple inward call. 
If an error occurs in ‘the lower “ring and ie “not handled there 
explicitly, PL/I dictates that the . signal. should propagate to the 
caller. However, since the caller ie in @ higher riag and has less 
privileges, chances are that it could act: deal with the actual error 
since it cannot affect datebases ia the lower ring. Thus, it seems 
useless to. allow signala to pass outward. But: apt allowing : signals to 
pass outward apparently contradicts, what was said: eatlier regarding high 
level handling of errors. Since the higher ares knows more about. the 
global situation it should have a say in mage abouild occur if an error 
is detected. This apparent conflict can ‘be resolved by the proper 
coding of the lower ring. The lower ting should not * sliow the higher 
fing to handle internal errors like "OVERFLOW", rather it should just 
“indicate a logical error in the lower ring. Then the higher ring can 
simply indicate that the lower ring should either retry the operation or 
abort. It is situations like this that Parnas may have been alluding to 
ie discussing “upward trape”. [Patnus 72b),, but he does not explicitly 
say it. Similarly, Goodenough’s "PASS" operation seems to pass on the 
handling of the original error. This is where I disagree; the fact that 


an error. occurred should be made known and a higher level should be 
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allowed to decided whether to continue or abort, but should not handle 


the original error. 


It is in situations like this that Multics falls down. On Multics, 
if an unhandled error is detected in a lower ring the computation is 
aborted. The outer ring is notified of this fact but cannot ask for a 
retry or continuation from that point. There is currently no general 
mechanism for inner ring programs teapectty is neeootGe and wait for 
outer ring intevention to continue. (18) The checkpoint feature allows 
some inner ring history to be preserved so that if continuation is 
desired, the inner ring need not recompute everything up to the point of 
the error; it would merely continue from the Pete aciie: The checkpoint 
feature, however, should not allow the sartiel-cesuien to be seen by the 
outer ring. Any other request given in between the time of the error 
and the continuation or abort should function normally and independently 
of the partial results held in the inner ring. The checkpoint is merely 
a technique to help improve efficiency in cases where the precomputation 
involves a sinificant amount of resource usage. However, the checkpoint 
feature is not required for the proper operation of the signalling 


mechanism. 


The second problem in multi-ring signalling has to do with outward 
calls. Outward calls is how the command environment that exists in an 


inner ring would call a user procedure. If the. default error handler 


(18) Errors during dynamic linking are an exception to this; they are 
handled as a special case and are "restartable". 
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should be protected as a common mechanism, signals have to travel from 


the outer ring to the inner ring to activate the default error handler. 


But there is.no way to guarantee that the mechantem used to transmit the 


condition from the outer ring to the finner ring’ is breakproof since it 


would involve outer ring: mechanitsnis: to: operate, |: 


To solve this problem the proceoure: that does the signalling in the 
outer ring can be peace in the inser ring (the protected environment). 
It would then be able. to signal conte ttons horeatty on the outer ring 
stack and then switch over to the inner fea? atecr if no handler were 
found or if there were an error while e attempting to signal such asa 


misthreaded stack in ‘the outer ‘ring. 


A final. problem discovered in multi<rtng ‘signalling has to do with 
an outward call followed by an inward: eall, In thls case there are two 
outstanding. invocations of the inner: ring. “Now, if thé ~ second 
invocation of the inner ring were a sdbipriicedure of the’ first, the 
second invocation might depend on condition Wandfers in its parent 
procedure. However, in the normal PL/T signelting ‘structure first the 
outer ring would have a chance of fielding an error in the second 


invocation of the inner ring before the expected handlers of the parent 


procedure in the inner ring would get control (1f ever). 


Using a debugger and figure 6:1 as an example, consider <A> to be 
the main procedure of the debugger and <A’> to be an internal procedure 
called by an activated breakpoint. Let <B> be the program that is being 


debugged. Now if <A’> signals a condition, <B> would! have a chance to 
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field it, not allowing <A>, the main debugger program, to properly 
handle it. This example is somewhat contrived and may not _ seem 
realistic enough to the reader. However, programs are written with 
internal procedures and the error handling may be expected to work this 
way. Because of the lexical proximity of the internal procedures, the 
programmer might not consider the problem discussed. Again the solution 
is complete specification of error handlers even in subprocedures, and 


elimination of the "dynamic descendence" rule. 
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Chapter Seven 


Implementation, Conclusions, and Future Research 


7.1 Implementation 


An implementation of some of the ideas in this thesis was 
undertaken to show that 1) the user environment can be partitioned in 
the manner described, 2) all the interactions between the environments 
were identified, and 3) rings are efficient for this separation. 
Multics was chosen as the system on which to implawent the test 
environment because’ it supports the process model described in chapter 
two and suffers from the problems described in chapters one and two. 
Furthermore, Multics has rings implemented in hardware which would 
undoubtedly help make the implementation efficient. Finally, Multics 


was an easily available system to experiment on. 


Chapter four discusses guidelines for support routine Scand that 
facilitate their separation and protection. Those ~ miiaciioss are 
basically modular design providing functional abstractions and data 
hiding. Experience with the test implementation reinforces the belief 
that protection would be simpler for those routines that followed the 
guidelines suggested, and harder for those that did not. In particular, 
both the event manager and timer manager (aiseuswed in chapter four) 


were designed and coded as functional abstractions. Thus, by merely 
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assigning those procedures to the lower user ring and writing simple 
transfer vectors as gates to the entrypaints, the event and timer 


mechanisms were protected. 


On the re hand, the design of the I/O system programs did not 
provide for information hiding. This forced I/0 access programs to know 
the exact layout of the control blocks and to manipulate the blocks 
directly because of the lack of functional abstractions. _ Although the 
ideas in the I/O system are good (streams with high level interactions) 
[Feiertag and Organick 71), the implementation made it impossible to 
protect any of the featurea of the 1/0 system. Not protecting the 1/0 
system as a whole did not affect the “connection” between the user and 
the écuiand and control environment, however... The attachment of the 

. terminal was "owned" by the inner ring and. thus could not be affected by 


user written programs. 


With the modules identified, the protected environment was 
established and a scheme for making outward calls and subsequent inward 
returns was designed and implemented. The functionality at _this point 
was that of the original Multics process; a user typed a command line 
and the specified programs were found, executed, and followed by a ready 
message. The only difference ig. that the specified command was 
executing in a ring of less privilege than the "normal! user ring, which. 


might cause the program to trip over incorrect access problems. (19) 


(19) Since users were basically not concerned with’ rings, and programs 
only ran in ai single ring, access was usually granted only to ring 4 
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Incorrect access to the command and control environment programs was 


just what was desired, though. 


Earlier I described how a user gets into the control environment. 
Briefly repeating it here, the user presses the break or attention key 
on the terminal and is then talking to the control environment. 
Examining how this is actually accomplished identifies a problem on 


Multics, 


The break is noted by eecniaal control sottqake in the supervisor. 
A process interrupt is generated which causes ‘he computation in the 
user’sS process to cease, and a condition "quit" -is signalled on the 
user’s stack in the PL/I defined manner. (20) Usually, the only handler 
for the quit condition is a default handler called when no _ other 
handlers have been found, and the bottom of. the stack is reached looking 
for one. At this point, the listener/command processor modules are 
called, essentially entering the command environment. The process 
interrupt acts just like an interrupt on other systems in the sense that 
control is torn away from the Succiitling procedure and is transferred 
elsewhere. This process interrupt essentially implements the "stop" 
mechanism of the control environment. Some of the commands the user may 
type actually execute in the protected environment, as described 


earlier, and perform the other control environment functions. 


(the default when setting access is to choose the current ring). Thus, 
initially, many access problems were encountered. 


(20) See chapter six for details on signalling. 


-89- 


Because the control environment is in a different ring now, care 
must be exercised to be sure that the quit signal is directed to that 
ring. Unfortunately, in the current system, all signals, including 
those arising from process interrupts, are signalled on the stack of the 
current ring of execution. This means that when actually executing a 
user program, the quit signal would be first signalled on the user 
program stack, and then, if directed properly, would continue on the 
protected environment stack. Thus, a destroyed user program stack could 


prevent returning to the control environment forever! 


Timers are implemented as process interrupts too. Thus an inner 
ring wishing to be notified at a certain time, or after a certain amount 
of chargeable execution time, would be subject to user stack integrity. 
This sort of dependency obviously violates ring structure and the goals 


set forward in chapters one and two. 


Recently a proposal a been made to solve this problem. The 
solution is simply to poll inner rings first when a process interrupt 
condition is to be signalled. Thus an inner ring has "first crack" at 
handling these conditions and would allow user programs to handle them 


only if they were of no interest to the inner ring at that time. 


The problem of user programs wanting to handle quits comes up again 
here. (21) The solution proposed in chapter five is useable here as 


well; the quit key can be multiplexed by some means and the proper 


(21) This was discussed in chapter five. 
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process interrupt will be generated depending on the "severity" of the 


abort that the user wanted. 


Error condition handling resulted in a study of error signalling 
"mechanisms in detail. The results of the study are presented in chapter 
six. The iaplementatisa 'finessed gome of the problems discussed in 
chapter six with special case code that handled the more common 


problems. : ‘ 


ia amon eetehe implementation proved that the proposed separation 
could be done, and furthermore, was Heliatively easy given a certain good 
style of coding to deal with. Simple experiments indicated that the 
cost of using the implementation wid approximately two to three times 
that of the original system when executing a program that did nothing 
more than return. For more complicated et an a the cost was 
essentially a fixed overhead (of two or three times the normal program 
invocation cost, as in the "nothing" program) which becomes 
insignificant when compared to a PL/I eer ree ee example. The 
cost can be expected to decrease if more aaece ake sharing the code, 


but the amount is not determinable. 
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7.2 Conclusions ‘ 


This thesis shows how system designers, interested in a system with 
verifiable security properties, and users of. ..system,; interested in 
self-protection measures, can both be satisfied by a rather simple 
hardware mechanism that proviies (at least) three protection 
“environments. Digital Pavtpasut Corporation included | three protection 
environments in the PDP 11/45 (and ‘extensions to 1), but failed to 
provide an ordering for all three; one environment, "kernel" node, was 
given usual supervisory privileges poe ‘the renaining two were left 
dabriateds This thesis discusses way ‘the ordering of privileges is 
needed and useful to facilitate “the establishnent of a program 
development environment. In addition, this thesie shows thet rings are 
indeed useful, and: suggests that designers should consider including ¢ a 


pie 
ring-like mechanian in new syatens. 
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7.3 Areas for Future Research 

Many of the concepts iigeusend in this thesis constitute areas 
needing more research. Primarily; the problems of the "ideal solution" 
require research and experience with. domain oriented systems to 
determine how the various components of the user environment should be 
managed. It may turn out that to solve some of the problems pointed out 
in chapter two, such as the access required by a linker or debugger, 


rings may be needed. 


Better high level languages with more intelligent compilers can 
help solve some of the problems of the programmer. More often than not 
it is the problem of representation of information that causes 
programmers to invent unclean techniques in their programming. CLU 
[Liskov 76] might help in this respect, allowing users to define 
extended type objects and procedures to manage them and preventing any 
other procedures from manipulating the internal structure of the 


extended type objects. 


The programmer’s apprentice concept [Hewitt] can be a very valuable 
aid to the programmer, but this seems years off. The concept of front 
end processors requires more research to decide the functionality and 
level of independence from the host required by the front end to make it 


suitable for use with differing machines, a collection of similar 
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machines (as in a network), and a combination of these two ideas. In 

the future we might encapsulate the complete command and control 
environment, discussed in chapter five, in a personal computer that 
would determine the resouces required for any command and dynamically 


acquire them from a network of resources. 
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_ Appendix A 


Certification and Kernel Simplification 


With the growing trend of entrusting computer based systems with 
important company. information and/or finances, as well as computerized 
cash flow, it becomes important to many companies to have a guarantee or 
proof that the system will not malfunction nor produce. erroneous 
results, because the system is now dealing with real dollars. Thus the 
concept of certifying a system came about seich meant that someone was 
willing to guarantee that a system functions properly under all 
circumstances and will not allow unauthorized modes of access to the 
system or data. In particular, the system has to be shown to 1) not 
release information to unauthorized personnel, 2) not allow unauthorized 
modification of information, and 3) not allow one user to deny service 
to another. It is hard to prove these types of negative attributes 
about a computer system because modern systems are so large and have 
many complex transactions going on within them. Many researchers are 
working on developing methods that can automatically verify that a 
system perforne ae specified, but even the specification techniques have 
not yet been perfected. One problem with developing specifications is 
that all the types of interactions peer fully known or understood 
especially in a system which has some degree of. undecidedness built into 
it (i.e. multiple processes and their scheduling). Automatic program 


verification techniques are still in their infancy and furthermore would 
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usually require rewriting the entire system in a new language with other 
constraints. Thus, the only alternative at this time is to review the 
code of the system manually and understand it fully so that it would 


then be possible to decide if the system is "secure". 


An approach to ease the.burden on a system certifier, or even make 
it possible, is to concentrate those programs deal ing with security into 
a security kernel and leave ait other. functions outside.” ‘This approach 
enables a certifier to ignore all those programs - outside -the security 
kernel, and thus leaves behind a smaller emount of: eode:.to be examined. 


It is obvious that less code. would be easier: to: review. and comprehend. 


Thus, any prourane not dealing with the security of the che system, a5, 
described by the three points mentioned “above; should be removed ‘fron 
the supervisor. | In keeping “with” ‘this ata, Janson and Bratt have 
described how. the dynaaik Linker and name epace manager can be removed 
from the Multics supervisor isaneon Th, arate 751. | 

In the past, however, there was another reason Wy ‘programé, which 
were primarily user programs, should not be in the supervisor. This 
reason was based on the . "principle. of - least privilege” 
[Saltzer and Schroeder 75] ‘when. deciding proper placement of a module. 
This principle, stated simply, means. that a program should only have as : 
much access as it needs to do its job. Otherwise programming errors in 
one program may lead to the destruction: or unrelated databases and other' 


programs, which obviously is fatal in a supervisor. 422) ‘This guideline 
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was followed as a simple rule of good design; but now, certification 
researchers realize that umneeded Sreebacnaes it harder to certify a 
system correct because it must be shown that programs do not’ take 
advantage of extra privileges they might posess in addition to showing 
that they do their job correctly. It is ibe dnieual.. to discover that 
good design principles also fit in well with certification work, as seen 


in this thesis. 


As a result of the certification work, it became apparent that the 
user environment would fill up with odutes that . were previously 
protected, and now these programs would be subject to the same 
programming errors that harm other user programs. This loss of function 
due to the increased fragility of the dade oaein iw what this thesis 


is about. 


(22) In fact, this is the same problem that is being attacked in this 
thesis, only this time the effects are more serious than a lost user 
process. 
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